Learning Paths

Five routes through this material, each ordered so that later pages build on earlier ones. Each path assumes no prior reading of the others.

---

1. New to digital health

For someone joining the field — a clinician moving into informatics, a developer new to health, a programme officer.

1. Glossary — skim it; return to it constantly
2. Architecture overview — the layers and the order in which decisions get made
3. Interoperability — the four levels; the single most useful mental model in this field
4. HL7 FHIR — the standard you will meet first
5. Standards directory — what else exists and what each is for
6. OpenHIE — how a national ecosystem is arranged
7. Registries — why identity comes before exchange
8. Health data — what health data is and why it is difficult
9. Maturity model — locate wherever you are working

The idea to take away: most failures blamed on technology are identity, terminology or governance failures one layer down.

---

2. Developer

For someone who will write integration code.

1. Interoperability — the four levels
2. HL7 FHIR — resources, REST, references
3. FHIR implementation guides — the key insight: nothing interoperates against "FHIR"
4. FHIR servers and HAPI FHIR — get one running
5. OAuth 2.0 and OpenID Connect
6. SMART on FHIR — build a launch flow
7. Terminology services — stop hard-coding code maps
8. HL7 v2 — because it is what you will actually be integrating
9. Integration engines and OpenHIM
10. FHIR Bulk Data and Subscriptions
11. Observability — and the rule about keeping patient data out of logs
12. DevSecOps — synthetic test data, and why

Practical exercise: stand up HAPI FHIR, generate synthetic patients with Synthea, load them, write a SMART app that reads observations, then validate everything against an implementation guide.

---

3. Health architect

For someone responsible for the shape of an ecosystem.

1. Architecture overview
2. Enterprise architecture — the capability/system gap table is the highest-value hour in this path
3. Architecture frameworks — and which ones are not health standards
4. OpenHIE, then all four of its component pages
5. Registries → client registry → facility registry
6. Health information exchange
7. Centralised vs federated HIE — the decision that shapes everything else
8. Terminology services
9. Identity, security and trust and consent and trust
10. Data architecture
11. Architecture patterns — the whole catalogue
12. C4 model and ADRs — how to write it down
13. Governance
14. Maturity model — assess your ecosystem
15. Checklists and templates

Practical exercise: run the maturity assessment with your team, requiring evidence for every score. The two lowest dimensions are your work programme.

---

4. Government and policy

For someone writing strategy, policy or tenders, who does not need to write code.

1. Awesome Health Architecture overview — the architecture map
2. WHO and global guidance — the documents that give your policy external legitimacy
3. Interoperability — particularly the organisational level, which is where programmes stop
4. Standards directory — enough to specify standards in a tender without naming products
5. OpenHIE — the ecosystem shape
6. Registries — the sequencing argument, and why the facility registry comes first
7. Digital public infrastructure — including the identity coverage and linkage risk questions
8. Consent and trust — consent models and trust frameworks
9. Governance — especially the procurement requirements list
10. Maturity model
11. Country architectures
12. Checklists

The two things to take into your next tender: require data extractability at exit with the cost stated in the contract, and require conformance to a named implementation guide demonstrated by test rather than asserted.

---

5. AI engineer in health

For someone building AI systems that touch health data.

1. Health data — what you are permitted to use, and what de-identification does and does not achieve
2. HL7 FHIR — the shape of the data
3. Terminology services — why coded data is not consistent across facilities
4. Data architecture — operational versus analytical
5. FHIR Bulk Data — how to get data out, and the governance that must accompany it
6. Machine learning — evaluation and deployment realities
7. AI architecture — where models attach, and the components beyond the model server
8. Clinical AI — regulation; read before building, not after
9. SMART on FHIR and CDS Hooks — the standards-based integration paths
10. MCP in healthcare — and why it is not a health standard
11. AI ethics and consent and trust
12. Governance — the AI governance section

The mistake to avoid: building on data that cannot be pooled. If terminology and identity are not sorted out, a model trained across facilities is learning the facility, not the patient. Check the maturity model before starting.

---

External learning resources

Resource	For
HL7 FHIR specification — https://hl7.org/fhir/	The primary source; the "Getting Started" pages are genuinely good
SMART Health IT tutorials — https://smarthealthit.org/	Building SMART apps
HAPI FHIR documentation — https://hapifhir.io/	Java FHIR implementation
DHIS2 Academy — https://academy.dhis2.org/	DHIS2 implementation and use
OpenHIE community — https://ohie.org/	Architecture and community calls
WHO Academy and WHO publications — https://www.who.int/publications	Policy and guideline material
HL7 connectathons — https://www.hl7.org/events/	The fastest way to learn FHIR properly
Synthea — https://synthetichealth.github.io/synthea/	Synthetic data to practise on

Connectathons deserve emphasis. Two days of implementing against other people's servers teaches more about interoperability than any amount of reading, including this.